1. Field of the Invention
The present invention relates generally to computer systems. More particularly, the present invention relates to ways in which access to a shared resource within a computer system may be controlled, ordered, guaranteed, etc. during an aspect of the application software development lifecycle.
2. Background of the Invention
As each day passes, the proliferation of computer-based devices progresses even further. In short, computers are everywhere—in the form of common desktop, laptop, pad and other portable systems, etc.; in servers, minicomputers, mainframes, etc.; in smartphones and other wireless devices; in televisions, television set-top boxes, Digital Video Recorders (DVRs), etc.; in appliances; in automobiles; etc.
In order for a computer to be useful, it must be appropriately directed. That direction traditionally comes through instructions in the form of a software application.
A programmer or a software developer typically creates a software application by writing source code in a high-level application programming language such as inter alia C, Java, C++, etc.
While high-level source code is easily understood by a human, it is effectively unintelligible to a computer.
Consequently source code is typically processed by a special-purpose computer program, commonly known as a compiler (i.e., the source code is compiled), to create possibly inter alia object code (i.e., instructions that can be executed by a computer).
The ever-increasing size and complexity of computer applications, the use of paradigms such as multi-threading (to for example improve performance as among other things the speed, capability, etc. of Central Processing Units (CPUs) increase), etc. lead, to a number of significant software development challenges.
One of those challenges concerns the ways in which different aspects of a software application (e.g., different functions, different threads of execution, etc.) contend over access to a shared resource such as inter alia a program variable; a memory location; a file, socket, etc. handle; a descriptor; etc.
The gravity of such contention—and the not-insignificant consequences (including inter alia the corruption of data, process or thread starvation, process or thread deadlock, etc.) when such contention is not properly managed, controlled, etc.—is readily understood by a person having ordinary skill in the relevant art. See for example Chapter 7 (“Isolation Concepts”) of the classic work “Transaction Processing: Concepts and Techniques” by Gray & Reuter.
One approach to the management, control, etc. of shared resource access involves the use of an execution-time synchronization primitive such as inter alia a lock, a Mutual Exclusion (mutex) object, a semaphore, a monitor, a latch, the application of a particular lock discipline, etc.
Imagine a doctor's office, having four examining rooms. Here a semaphore, set initially to a value of four (indicating the number of empty examining rooms), could be employed to control access to the examining rooms (i.e., shared but limited resources). The value of the semaphore would be decremented by one when a patient enters an examining room and the value of the semaphore would be incremented by one when a patent exits an examining room. When the value of the semaphore reaches zero then patients would need to queue in the lobby of the doctor's office (i.e., a request for an available examining room would be blocked) until a patent leaves an examining room (and the value of the semaphore is incremented by one).
In a simpler environment, for example in a small doctor's office with just one examining room, a special case of a semaphore, with a value of one, known as a mutex could be used to serialize access to the examining room (i.e., a shared but limited resource). The mutex would ensure that only one patient gains access to the examining room at any given time, resulting in for example other patients queuing in the lobby of the doctor's office (i.e., a request for the examining room would be blocked) until the first patent leaves the examining room.
Other execution-time artifacts, beyond a semaphore and a mutex, are easily possible and indeed other numerous execution-time mechanisms have over the years been developed and employed to control access to shared resources.
While execution-time checks, controls, etc. remain important (since it is not possible to fully predict shared resource access contention, deadlocks, etc. at the time of execution), it would be desirable to provide an additional level of protection by identifying, controlling, ordering, etc. at least aspects of shared resource access at the time of source code compilation.
Thus, a need exists for a flexible, extensible, efficient, etc. compile-time mechanism that leverages native high-level application programming language constructs (such as for example the template, macro, etc. features of C++), thus minimizing any programmer or a software developer learning curve and eliminating the need for programming tool (e.g., compiler) changes, to help improve the elimination of among other things the problems of starvation and deadlock.
Aspects of the present invention fill the lacuna that was noted above while addressing, in new and innovatory ways, various of the not insubstantial challenges that are associated with same.